The present application relates to digital data processing, and more particularly to storing and using classes in databases.
FIG. 1 illustrates a client/server system 50 in which a network 75 links a server 80 to client systems 60A, 60B, 60C. The server 80 is a programmable data processing system suitable for implementing apparatus, programs, or methods. The server 80 provides a core operating environment for one or more runtime systems that process user requests. The server 80 includes a processor 85 and a memory 90. The memory 90 can be used to store an operating system, a Transmission Control Protocol/Internet Protocol (TCP/IP) stack for communicating over the network 75, and machine-executable instruction code executed by the processor 85. In some implementations, the server 80 can include multiple processors, each of which can be used to execute machine-executable instructions. An example of a suitable server that can be used in the client/server system 50 is a JAVA 2 PLATFORM ENTERPRISE EDITION™ (J2EE) compatible server, such as the Web Application Server developed by SAP AG of Walldorf (Baden), Germany (SAP), or the WebSphere Application Server developed by IBM Corp. of Armonk, N.Y.
Client systems 60A, 60B, 60C can execute multiple applications or application interfaces. Each instance of an application or an application interface can constitute a user session. Each user session can generate one or more requests to be processed by the server 80. The requests can include instruction code to be executed on a runtime system (e.g., the virtual machine 100) on the server 80.
A runtime system is a code execution environment that executes instruction code in user requests and that provides runtime services for that code. Core runtime services can include functionality such as process, thread, and memory management (e.g., laying out objects in the server memory 90, sharing objects, managing references to objects, and garbage collecting objects). Enhanced runtime services can include functionality such as error handling and establishing security and connectivity.
One example of a runtime system is a virtual machine. A virtual machine (VM) is an abstract machine that can include an instruction set, a set of registers, a stack, a heap, and a method area, like a real machine or processor. A VM essentially acts as an interface between program code and the actual processor or hardware platform on which the program code is to be executed. The program code includes instructions from the VM instruction set that manipulates the resources of the VM. The VM executes instructions on the processor or hardware platform on which the VM is running, and manipulates the resources of that processor or hardware platform, so as to effect the instructions of the program code. In this way, the same program code can be executed on multiple processors or hardware platforms without having to be rewritten or re-compiled for each processor or hardware platform. Instead, a VM is implemented for each processor or hardware platform, and the same program code can be executed in each VM. The implementation of a VM can be in code that is recognized by the processor or hardware platform. Alternatively, the implementation of a VM can be in code that is built directly into a processor.
As an example, a JAVA™ source program can be compiled into program code known as bytecode. Bytecode can be executed on a Java VM running on any processor or platform. The Java VM can either interpret the bytecode one instruction at a time, or the bytecode can be further compiled for the real processor or platform using a just-in-time (JIT) compiler.
In addition to Java VMs, other examples of VMs include Advanced Business Application Programming language (ABAP) VMs and Common Language Runtime (CLR) VMs. ABAP is a programming language for developing applications for the SAP R/3 system, a widely installed business application system developed by SAP. The Common Language Runtime is a managed code execution environment developed by MICROSOFT® Corp. of Redmond, Wash. For purposes of simplicity, the discussion in this specification focuses on virtual machines, but it is to be understood that the techniques described herein can also be used with other types of runtime systems.
A VM typically begins execution by invoking a method of a specified class. This invocation causes the specified class to be loaded, linked to other types that it uses, and initialized. The VM will typically check first to determine if the class has already been loaded. For example, the VM may have previously loaded the class into a local cache area. If not, however, the VM will use a class loader to attempt to find the class, which is represented in binary form. A class loader extends the way in which the VM dynamically loads and creates the class in a platform-specific manner. For example, a VM running in one hardware or software environment may load the class differently than a VM running in a different hardware or software environment.
The class loader may be a bootstrap class loader supplied by the VM or a user-defined class loader. The bootstrap class loader is responsible for loading basic class library classes. The VM may also have access to other types of class loaders. The user-defined class loader can be used to create a class that originates from user-defined sources. The VM often uses a special variable, referred to as a “class path” variable, to locate classes for loading. For example, the user-defined class loader may utilize the class path variable to locate user-defined classes. The class path variable may specify various file directories in which the VM is to look for classes. Multiple classes are often archived and stored in these file directories. For example, in JAVA environments, JAVA archives (JAR's) may be stored in these directories. The JAR's may include multiple classes in compiled form, along with other information associated with these classes.
Once the VM has loaded a given class, it then links the class to other types (e.g., classes or interfaces) that it uses. Linking is the process of taking a binary form of a class or interface type and combining it into the runtime state of the VM so that it can be executed. Linking typically involves verification, preparation, and resolution of symbolic references. Finally, after the VM has loaded and linked the class, it may initialize the class by executing any class variable initializers and static initializers. In certain contexts, the term “loading” or “class loading” may refer to the combined processes of loading, linking, and initialization of classes.